Subject: DLUR Architecture Change Proposals Now Available For Review

From: Ed Tremblay <[email-masked]>
Date: Tue, 12 Mar 1996 15:52:54 -0500 (EST)

(We're having more problems sending e-mail through our gateway, so I'm
trying another method - it doesn't show a correct return address; my
correct address is at the bottom of the note)

Proposals to change the APPN DLUR Architecture Reference manual have 
been placed on networking.raleigh.ibm.com for items 8334, 8343, 8345,
8363, 8372, 8375, and 8382.  These files can be found in directory   
/aiw/dlur:                                                           
                                                                     
     abs8334.txt                                                     
     arch8334d.psbin                                                 
     abs8343.txt                                                     
     arch8343d.psbin                                                 
     abs8345.txt                                                     
     arch8345d.psbin                                                 
     abs8372.txt                                                     
     arch8372d.psbin                                                 
     arch8382f.psbin (also includes change pages for 8375)           
                                                                     
These files for item 8363 can be found in directory                      
/aiw/appn/architecture:                                                  
                                                                         
     arch8306.psbin                                                      
     toponver.psbin                                                      
                                                                         
8334) DLUR strategy for DLUS searches                                    
                                                                         
      Jim Fletcher made this proposal:                                   
                                                                         
        I'd like to propose that we add an item to the DLUR architecture 
        with regards to "locating a DLUS". I am afraid that we will have 
        products that attempt to locate the DLUR "endlessly" and flood   
        the network with broadcasts in doing so.                         
                                                                         
        I propose that we indicate in the architecture that products     
        should use a "sliding" timer when locating the DLUS so that for  
        example the first look is immediate, second at 1 minute, third   
        at 4 minutes, then 8, 16, etc ...                                
                                                                         
      The DLUR architecture reference section 5.7.1, "CPSVRMGR Session   
      Recovery", has been updated concerning retry strategy when a       
      Locate for a DLUS fails, as follows:                               
                                                                         
      The DLUR should never become "dead" but should be able to access a 
      DLUS whenever one becomes available.  It is recommended that all   
      DLUR implementations incorporate the key concepts of:              
                                                                         
         - alternating retry attempts between different DLUSs           
         - increasing the time between retries later on                 
         - never giving up attempting to acquire a DLUS                 
                                                                        
      For example, a DLUR could attempt to acquire a DLUS until         
      successful using the following retry procedure:                   
                                                                        
         1) Immediately retry to the same DLUS                          
         2) After some time t, retry to same DLUS again                 
         3) After some time t, try the backup DLUS                      
         4) Toggle between primary and backup up to m times             
         5) If still no success, toggle back and forth between primary  
            and backup at t+n intervals forever.                        
                                                                        
8343) DLUR redriving SSCP-PU activation after receiving DACTPU          
                                                                        
      There is a problem with DLUR connected devices, where the         
      attaching device is also a type 2.1 node with independent         
      sessions.                                                         
                                                                        
      The scenario is a CM/2 attached via a single link to a 950 DLUR.  
      The device is connected into the 950. No CONNOUT from VTAM was    
      permitted.                                                        
                                                                        
      When VTAM DACTPUed the device PU, the 950 DLUR also inactivated   
      the connection between the DLUR and the CM/2, killing CP-CP       
      sessions and LU-LU sessions.  The reasoning was that there was no 
      other means to cause the CM/2 to re-enable its SSCP-PU session,   
      since no "connout" capability was coded in VTAM.                 
                                                                       
      There is agreement that the 950 should NOT deactivate the        
      connection.  Instead, when a DACTPU is received at the DLUR for a
      downstream PU, if the DACTPU is not the result of a previous     
      REQDACTPU, and the original connection was established via       
      REQACTPU, then the DLUR will immediately send a REQACTPU back to 
      the DLUS.  This will redrive the connection and reestablish the  
      SSCP-PU session while not impacting other sessions.              
                                                                       
      The DLUR DACTPU processing summary is as follows:                
                                                                       
                    ------------------------                           
                    ! DLUR receives DACTPU !                           
                    ------------------------                           
                               !                                       
                 --------------------------------                      
                ! result of previous REQDACTPU ? !                     
                 --------------------------------                      
                      ! N                   ! Y                        
         ---------------------         -----------------               
        ! original connection !        ! Link Outage ? |               
        ! sent by REQACTPU ?  !        -----------------               
         ---------------------            !Y         !N                
            ! Y            ! N        Clean up    --------------       
    ---------------------  !-------!  everything  ! PU outage? !       
    ! DACTPU(giveback)? !        -----            --------------       
    ---------------------        ! A !             !Y       !N         
        ! Y        ! N           -----   Clean up PU/LU   Discontact PU  
        !     -----------------            sessions       Clean up PU/LU 
        !     ! send REQACTPU !          Keep link up       sessions     
        !     ! to same DLUS  !            unless ...     Keep link up   
        !     -----------------            (see A)          unless...    
        !                                                   (see A)      
    --------------------------                                           
    ! Active LU-LU sessions? !                                           
    --------------------------                                           
       ! Y               ! N                                             
   -----------------   -----                                             
   ! Send REQACTPU !   ! A !==> Clean up SSCP-PU/LU sessions             
   ! to other DLUS !   -----    Retain LU-LU sessions if DACTPU type and 
   -----------------            ANS allow it                             
                                Keep link up unless link type requires it
                                (e.g., short hold mode                   
                                       limited resources                 
                                       maybe switched with all link      
                                       stations inactive)                
                                                                         
8345) DLUR handling Locates with OCR on while LU or pipe is inactive     
                                                                         
      John McGinn of AS/400 submitted the folllowing request:            
                                                                         
        I am trying to determine what the criteria should be for a DLUR  
        to send a positive response on a Locate that it receives with    
        the OCR bit on.  Assume that we have some pre-defined dependent  
        LUs that reside on our DLUR.  Should we only positively respond  
        to search requests with the OCR bit on if the particular         
        dependent LU has positively responded to an ACTLU from the DLUS? 
                                                                         
        The real reason for my question boils down to how NNS Processing 
        for Option Set 1116 is defined.  According to the architecture,  
        an NNS supporting this option set will delete/retain the         
        registered resource pending the results in the Locate reply.  If 
        a DLUR is only supposed to reply positively on a search if it    
        has successfully processed ACTLU, then this means that I cannot  
        register dependent LUs until they have gone through this ACTLU   
        processing (otherwise they will be deleted by the NNS upon a     
        negative search response from the DLUR).  I see this as a bad    
        thing because I will now be forced to register only a single     
        dependent LU at a time (since they become ACTLU'd serially).     
                                                                         
        What I would really like to see is for an NNS not to delete      
        the registered resource based upon a negative search reply.      
        This way, a DLUR could register ALL of it's pre-defined          
        dependent LUs once their CP-CP session with the NNS becomes     
        active.  This would be far more efficient than registering      
        these dependent LUs one at a time and having to provide         
        constant registration updates based upon the status change      
        caused by ACTLUs and DACTLUs being received.  Comments?         
                                                                        
      Therefore, if the DLUR has a predefined or dynamically created LU 
      for which it has received a Locate with OCR on, the DLUR should   
      reply Found to the Locate regardless of whether the LU is active  
      or not.  It also should register the LUs right away and not wait  
      until they are active; let the NNS turn around all of the non-OCR 
      Locates as soon as possible, and have the DLUR reject the Locate  
      only if the LU is not there.                                      
                                                                        
      Because the Locate with OCR on is generated after the DLUS gave   
      its OK to the session, the DLUR could reply Found even with the   
      pipe down in the hope that the pipe will come back up before the  
      BIND arrives.                                                     
                                                                        
      A Found returned by the DLUR with the pipe down cannot include a  
      CV X'40' = DLUS since there is no current DLUS.  Therefore,       
      CV X'40' will not be included in the Found when there is no       
      active CP-SVR pipe.                                               
                                                                        
      Responding positively to the Locate request removes the need for  
      the DLUR to remember which dependent SLUs it needs to re-register. 
      It will also allow the search to be terminated at that point,      
      instead of performing a network broadcast, subarea search, border  
      node search, etc.  It will also allow the DS database caches at    
      CDS nodes and EBNs to retain knowledge of where the dependent LU   
      resides.  That way, when the DLUR subsequently obtains a new DLUS, 
      network broadcast searches may be avoided.                         
                                                                         
8363) Clarification of assignment of option set 1116                     
                                                                         
      DLUR architecture introduced the function called DLUS-Served LU    
      Registration NNS support and selected option set 1116 for this     
      function.  However, option set 1116 was never reserved for this    
      function in Appendix A of the APPN Architecture Reference.  Later, 
      item 8306 was opened for the Bypass of Directed Locate Not Allowed 
      function, and it reserved option set 1116 in Appendix A for this   
      function.  Only one function can use option set 1116 and the other 
      must be assigned a new option set number.                          
                                                                         
      Appendix A of the APPN Architecture Reference has been updated     
      with DLUS-Served LU Registration NNS Support defined as option     
      set 1116 and Bypass of Directed Locate Not Allowed changed from    
      option set 1116 to option set 1117.  Item 8306 (Topology           
      Non-Verify Bypass) has been updated to reflect the change from     
      Option set 1116 to 1117.  The change pages are on the AIW ftp      
      server (arch8306.psbin and toponver.psbin on                       
      /aiw/appn/architecture).  The CP-Capabilities file has also been   
      updated for the SNA Formats manual.                                
                                                                         
8372) Clarify sense code used for "surprise" CP-SVR pipe activation      
                                                                         
      Section 5.7.3.2 and Figure 5-19 of the APPN DLUR Architecture      
      Reference Version 1.2 discuss the processing for "surprise" CP-SVR 
      pipe activation.  Included in that processing is rejecting the new 
      activation request.  However, it has been pointed out that the     
      specific sense code used is not indicated in the reference.  DLUR  
      implementers have reported X'0805 0000' is used for this           
      situation.                                                         
                                                                         
      This sense code will be used both when -RSP(BIND) can be sent and  
      when due to timing situations an UNBIND is sent instead.           
                                                                         
      This information will be added to Section 5.7.3.2 and to Figure    
      5-19.                                                              
                                                                         
8375) Change of APPN frame-relay signaling information formats           
                                                                         
      The signaling information in CV X'46 subfields X'93' and X'95'     
      for frame-relay has destination and source SAP, respectively,      
      encoded in canonical format.  Some products, however, transmit     
      the SAPs in noncanonical format, just as they do for token-ring.   
      The present encoding of CV X'46' has led some others to conclude   
      that the SAPs for frame-relay are being transmitted on the wire    
      in canonical format.  The purpose of this item is to resolve this  
      confusion.                                                         
                                                                         
      The signaling information in CV X'46' subfields X'93' and '95'     
      currently defines the DSAP and SSAP, respectively, in canonical    
      (i.e., ISO/IEEE 8802) format for frame-relay.  Some products,      
      however, convert the DSAP and SSA frame-relay to noncanonical      
      (token-ring) format before transmitting them.  In order to remove  
      this source of confusion to other APPN vendors, the format for     
      the DSAP and SSAP for frame-relay is being changed to              
      noncanonical.  Making this change also avoids a migration problem  
      in moving from subarea to APPN.                                    
                                                                         
8382) Change of APPN V.25 bis signaling information formats              
                                                                         
      A new alternative to deliver signaling information in CV X'46' for 
      the V.25 bis physical interface is requested.  At present, SF93    
      conveys the destination dial address and SF94 conveys the calling  
      identification number.  This presents a problem for DLCs that are  
      expecting full dialing instructions from the higher layers.        
      In addition to the destination number, for example, it is          
      necessary to send a three-character command to the V.25 bis modem. 
      VTAM assembles the full string of commands and numbers and         
      transports them in DIALNO.  The only operation needed before       
      passing this information to the modem is to convert the EBCDIC     
      characters to IA5 characters.                                      
                                                                         
      The architecture will define SF95 to convey this same string of    
      characters in CV46 for V.25 bis.  There would be two alternatives: 
                                                                         
        1) Subfields 93 and 94 could be used where the DLC is capable of 
           adding the appropriate command and separator characters.      
                                                                         
        2) Subfield 95 could be used instead of 93 and 94.  All needed   
           characters would be included in the new subfield.             
                                                                         
      SF95 will allow any legitimate V.25 bis character to be included.  
      The specific characters allowed will depend on the modem and       
      telephone network being used.  A maximum length of 64 bytes is     
      being defined for subfield X'95'.                                  
                                                                         
I'm requesting approval of these items at the next AIW during the APPN   
Reference SIG session.                                                   

--------------------------------------------------------
Ed Tremblay                      [email-masked]